Field
Embodiments generally relate to providing access to large data sets in systems using virtual applications.
Related Art
Large medical applications manage large amounts of data and consume considerable resources (e.g., processing and memory resources). For example, the diagnosis of a heart that analyzes the ventricle and the vessels in 2D and 3D, based on one large data set of the heart (e.g., a computed tomography scan).
The large size of the medical application enlarges start-up times and also the time a user needs to switch between applications in order to perform application specific objectives needed for a diagnosis. The large amount of data causes considerable load times and the necessary memory consumption can be large enough to block other users on a server hosting the data. Limitations associated with a display device and constraints associated with usability (e.g., legal and technical) do not always allow for including all functionality into one giant diagnosis application.
As a result, the known approaches include tying clinical diagnosis workflows to a series of specialized applications. This may minimize the size of the application and the limitations associated with a display device. Each specialized application allows the user to alter the medical data accordingly. On the other hand, these specialized applications alter the large amount of data independently of each other.
As a result, the data is reproduced across each of the specialized applications, in addition to cross application notification and integration complexities, in order to consolidate the result set in the end and allow a hand-over to the next workflow step. Further if the specialized applications reload intermediate results in order to allow continue working, the re-distribution of the data creates additional complexity and footprint growth.
Without additional complex systems, the stepwise diagnosis requires seeing changes in all contributing applications. A selected application has to reload the changed data again and merge the selected application's changes to the data at the same time, which gives contradictions, which increases the load time of the selected application and because the selected application code base has to behave like the foreign application in order to show the user a consolidated change state of the data (also across applications) and even allow editing, thus again behave like a large application.
FIG. 1 illustrates conventional art client-server system. As shown in FIG. 1, the client-server system 100 includes a client (or front end) 105 and a server (or back end) 110. The client 105 includes a processor 120, a memory 125, an operating system 140 and a virtual application (VAP) 150. The server 110 includes a processor 130, a memory 135, an operating system 145, a virtual application (VAP) 155 and data 160.
A virtual application may describe software technologies that improve portability, manageability and compatibility of applications by encapsulating them from the underlying operating system on which they are executed, and from the product specific run-time infrastructure that hosts and services applications. A virtual application may be software executing on a physical machine which emulates an independent and separate application from other virtual applications which may be emulated on a physical machine (e.g., a client, a server or a physical entity).
A single physical machine may host multiple virtual applications. A virtual application may emulate physical machine and be known in the art as a virtual machine. A virtual application may emulate a known software application. For example, the virtual application may emulate a word processor, imaging editing software, software to operate a device (e.g., a medical imaging device) and the like. For virtual machines, the same holds as for physical machines.
As is shown in FIG. 1 VAP 150 and VAP 155 may interact with each other. For example, in a client-server system a client virtual application (e.g., VAP 150) may perform a user interface function. For example, the client virtual application may display images or data, provide user input/output, control peripheral devices and the like. In a client-server system, a server virtual application (e.g., VAP 155) may perform a back end function. For example, the server virtual application may provide access to data (e.g., data 160) to the client virtual application.
In a standalone system (e.g., no client-server relationship) one virtual application (e.g., VAP 150) may perform both the client and the server functions. For example, the one virtual application may provide both a user interface function and a data access function.
As is known, one client may be configured to run a plurality of virtual applications. The plurality of virtual applications may be standalone or interact with a server. If each of the plurality of virtual applications access a same data set (e.g., medical image data), the same data set is replicated for each of the plurality of virtual applications. This data replication results in over utilization of system resources (e.g., processor and memory resources).
As one skilled in the art will appreciate, as the size of the data set increases and/or the number of virtual applications increases, system resources will be strained. As a result, system designers over scale the quantity of resources resulting in excess costs in the manufacture of devices (e.g., medical imaging devices), or generate complex and costly resource management, with potentially limited success. Alternatively, system designers allow for reduced system performance as system resources are strained, or alternatively, let the user adjust to poor system performance.